High Efficiency Video Coding (HEVC) is a new coding standard that has been developed in recent years. In the High Efficiency Video Coding (HEVC) system, the fixed-size macroblock of H.264/AVC is replaced by a flexible block, named coding unit (CU). Pixels in the CU share the same coding parameters to improve coding efficiency. A CU may begin with a largest CU (LCU), which is also referred as coded tree unit (CTU) in HEVC. In addition to the concept of coding unit, the concept of prediction unit (PU) is also introduced in HEVC. Once the splitting of CU hierarchical tree is done, each leaf CU is further split into one or more prediction units (PUs) according to prediction type and PU partition.
In contrast to the conventional natural video with a continuous colour tone, screen content video often contains a few pilot colours and sharp edges and boundaries. Several new tools are currently under investigation for potential adoption into the HEVC SCC (Screen Content Coding) extension. For example, in JCTVC-R-1005 (Joshi, et al., High Efficiency Video Coding (HEVC) Screen Content Coding: Draft 1, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 18th Meeting: Sapporo, JP, 30 Jun.-9 Jul. 2014, Document: JCTVC-R1005), a palette is utilized to represent a given video block (e.g. CU) with limited number of values. Some related terms are illustrated as follows.                1. Palette table: A mapping table to map from a pixel value to an index. The palette table is also referred as palette in this disclosure.        2. Colour index map: Mapped pixel indices associated with values in the block. The colour index map is also referred as palette indices of the block.        
For HEVC SCC, both the palette and the colour index map have to be signalled. For example, decoding and parsing processes have been disclosed in JCTVC-R0348 (Onno, et al, “Suggested combined software and text for run-based palette mode”, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 18th Meeting: Sapporo, JP, 30 Jun.-9 Jul. 2014, Document: JCTVC-R0348). For the colour index map signalling, the pixels in the block can be coded in horizontal raster scan order, vertical raster order, horizontal traverse scan order or vertical traverse order. Various palette index prediction modes, such “copy above mode”, “index mode”, “Escape mode”, etc. can be used. In addition, the number of palette indices in each block is also signalled.
In the draft HEVC SCC standard disclosed in JCTVC-U1005 (Joshi, et al., HEVC Screen Content Coding Draft Text 3, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 20th Meeting: Geneva, CH, 10-18 Feb. 2015, Document: JCTVC-T1005), binarization method for the number of indices is disclosed. In JCTVC-U1005, the number of indices minus 1 (i.e., num_palette_indices_minus1) is first signalled. The prefix part is coded using Truncated Rice (TR) code. The suffix part is coded using kth-order Exp-Golomb (EGk) code. The Truncated Rice binarization process uses parameter, cRiceParam, to derive the prefix part. In particular, when num_palette_indices_minus1<(3<<k), the TR code is used and k is the Rice parameter. Otherwise, EGk code is used with preceding “111”. The “<<” in the above equation corresponds to the left-shift operation.
The Rice parameter cRiceParam (i.e., k) is derived as:cRiceParam=3+((MaxPaletteIndex+1)>>3),  (1)according to JCTVC-U1005, where “>>” corresponds to the right-shift operation.
Some examples of TR and EGk binarization processes are shown as follows. Table 1 illustrates an example with cRiceParam(k)=0 with 0th-order EG (i.e., EG0) and Table 2 illustrates an example with cRiceParam(k)=2 with 2nd-order EG (i.e., EG2):
TABLE 1k = 0PrefixSuffix (EG0 code)001102110311104~511110X6~9111110XX. . .. . .. . .
TABLE 2k = 2PrefixSuffix (EG2 code)0~30XX4~710XX 8~11110XX12~151110XX16~2311110XXX24~39111110XXXX. . .. . .. . .
According to the existing HEVC SCC draft (i.e., JCTVC-U1005), the cRiceParam may be very large. For example, the maximum cRiceParam can be 11, 19, 35, and 131 for palette size equal to 63, 127, 255, 1024 (i.e., 32×32) respectively. In other words, the worst-case number of the coded bins equal to 132 (i.e., cRiceParam+1) for a 32×32 CU, which is extremely long. There are redundant bits present in the case of large cRiceParam. If the fixed-length (FL) code is used, there will be no more than Log 2CUSize bins using FL binarization, where Log 2CUSize=Log2(CU size). Therefore, only 6, 8 and 10 bins will be needed for 8×8, 16×16, and 32×32 CUs respectively. According to the existing HEVC SCC draft, cRiceParam determines the minimal length of the FL suffix part. Therefore, when cRiceParam is greater than or equal to Log 2CUSize, the prefix is always equal to 0 and some redundant leading 0 bins are present. For example, 6 redundant “0” bins will be present in the binarization of the number of palette indices minus one (i.e., syntax num_palette_indices_minus1) for 8×8 CU with palette size equal to 63.
Therefore, it is desirable to improve the coding efficiency associated with colour index map coding.